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(57) The present invention provides a protocol for 
the transfer of files to and from electronic devices, es- 
pecially wireless devices. In one embodiment, the 
present invention is used by these devices connected 
by any means to the source of the file. These means 
can be wireless, modem dial-up, or conduit of a PDA. 
Since the present invention is used by wireless devices 
which operate on limited and expensive wireless band- 
width, it is not verbose and "chatty" unlike prior art pro- 
tocols based on clear-text HTML ,XML, or HotSync. The 
present invention uses HTTP or HTTPS to connect two 
devices communicating with each other. HTTP is used 
since it is a protocol that is usually allowed to traverse 
virtual private network firewalls. The invention allows the 
server to maintain multiple sessions with different cli- 
ents. These sessions will end automatically if no data is 
transferred after a certain length of time has elapsed. 
These different clients can connect and perfonn opera- 
tions concurrently with each other. The present inven- 
tion supports the following operations, viz.: Identify and 
Authenticate, List, Get, Replace, Add, Delete, Cancel, 
and Logout. The Invention allows for synchronous trans- 
fer of messages to and from the wireless devices. The 
present invention, in one embodiment, lets the client in- 
itiate the transfer. The server does not automate the 
transfer unless a request is made by the client. 
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Description 

BACKGROUND OF THE INVENTION 

1 . FIELD OF THE INVENTION 

[0001] The present invention relates to the field ot 
transferring data to and fronn wireless devices. 
[0002] Portions of the disclosure of this patent docu- 
ment contains material that is subject to copyright pro- 
tection. The copyright owner has no objection to the fac-. 
simile reproduction by anyone of the patent document 
or the patent disclosure as it appears in the Patent and 
Trademark Office file or records, but otherwise reserves 
all rights whatsoever. 

[0003] Sun, Sun Microsystems, the Sun logo, Solaris 
and all Java-based trademarks and logos are trade- 
marks or registered trademarks of Sun Microsystems, 
inc. in the United States and other countries. All SPARC 
trademarks are used under license and are trademarks 
of SPARC International, Inc. in the United States and 
other countries. Products bearing SPARC trademarks 
are based upon an architecture developed by Sun Mi- 
crosystems, Inc. 

2. BACKGROUND ART 

[0004] Small computing devices such as Personal 
Digital Assistants (PDAs) are becoming increasingly 
popular One of the advantages of small computing de- 
vices is their portability and their ability to interact with, 
and share data with, a desktop computing system. How- 
ever, their portability means that computing resources, 
such as memory and processing power, may be limited. 
Furthennore, current wireless networics suffer from low 
bandwidth, and high latencies. These can be a problem 
In implementing protocols for transferring files between 
a desktop environment and the smalt device, particulariy 
in a wireless environment. This problem can be better 
understood by reviewing PDAs and file transfer proto- 
cols. 

PDA 

[0005] A PDA is a small computer-like device, usually 
no larger than the palm of a human hand, which typically 
has a base housing with an input mechanism mounted 
on its topside, and a miniature display screen for output. 
Figure 1 Is an illustration of one embodiment of a per- 
sonal digital assistant. The PDA (100) shown in Figure 
1 is manufactured by Palm™. The PDA has a base 
housing (160) with input mechanisms mounted on its 
topside, and a miniature display screen (110) for output. 
The base housing of the PDA contains a small micro- 
processor, data storage and memory areas, a storage 
battery, and other various miniature electronic compo- 
nents. The electronic components and other features 
vary depending on the model, make, and manufacturer 



of the PDA. The PDA is activated and de-activated by 
accessing the power button (150). 
[0006] PDA output may take the form of either graphic 
and/or textual images presented to users on the minia- 

5 ture display screen , or may be presented to users in the 
form of sound. Additionally, some PDAs can package 
infomnation for output through cable or wireless net- 
works. Thus, data is transmitted to a general purpose 
computer. Likewise, data transfers from general pur- 

10 pose computers to PDAs via the same mechanism. 
[0007] The input mechanism may be, for example, a 
miniature keyboard (not shown). Alternatively the min- 
iature display screen may act as both an input and out- 
put mechanism. When used as an input mechanism, the 

15 user inputs the data via a pen-like stylus or other writing 
implement (not shown) directly on the display screen. 
This could take the fomn of handwriting, or highlighting 
certain specific areas on the display screen such as but- 
tons, icons, or captions. With reference to Figure 1 , the 

20 bottom portion (1 20) of the display screen is where the 
user provides input using the pen-like stylus. Additional 
mechanisms for user input include a scroll button (130) 
and application buttons (140). 

[0008] Conventional PDAs also contain an operating 

25 system and other programs, such as word processing, 
spreadsheet, e-mail, calendar, memo list, stylus pen ap- 
plications, and other related applications. The increas- 
ing popularity of PDAs stems from their relatively low 
cost and extreme portability compared to much larger 

30 desktop general-purpose computers ("desktop CPUs"). 
Many users find that for simple computing tasks during 
trips and other periods of being away from their larger 
computer devices, the bulk and computing power of 
even a compact notebook computer are simply not 

35 needed. PDA popularity also stems from the fact that 
they can commun icate with most popular desktop appli- 
cations like spreadsheet programs, word processing 
programs and e-mail. Thus, transfer of data between 
PDAs and general purpose desktop computers is pos- 

40 sible. 

PDA DATA TRANSFERS AND CONDUIT 

[0009] A conventional means of transferring data is 
45 by way of a conduit. Figure 2 illustrates one mechanism 
by wh ich a user transfers data from a desktop CPU (200) 
to a PDA (210), or vice versa. The desktop CPU couples 
to the PDA can^iage (220) via a connecting line (230). 
The connecting line represents a conduit. 
50 [0010] A conduit provides a two-way data communi- 
cation coupling via a desktop CPU to a PDA. Although, 
the conduit represents a cable connection, it will be ap- 
parent to one skilled in the art, that the present invention 
may be practiced with numerous types of connections. 
55 For example, if the conduit is an integrated services dig- 
ital network (ISDN) card or a modem, the conduit pro- 
vides a data communication connection to the corre- 
sponding type of telephone line. Additionally, wireless 
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links are available to the present invention. In any such 
implementation, the conduit sends and receives electri- 
cal, electromagnetic or optical signals, which cany dig- 
ital data streams representing various types of informa- 
tion. 

[0011] In operation, a user inserts the PDA into the 
carriage in the direction generally indicated by the black 
arrow (240). Thereafter, data is passed bi-directionally 
across the conduit to achieve the result of transferring 
data between a PDA and a desktop general purpose 
computer. 

PDA TRANSFERS 

[0012] In addition to hardwired transfer schemes, 
PDA's are often used to access data and service via 
wireless connections. However, due to size limitations, 
PDAs have less memory and processing resources than 
desktop general purpose computers! Thus, conserva- 
tion of memory and storage space, and implementing 
simple protocols, is a main concern when designing pro- 
grams for use on PDAs. If protocols are too complex, 
they may tax both the processing resources and mem- 
ory capabilities of the PDA. In addition, it is typically de- 
sired to use wireless communication with a data or file 
source, for convenience. Wireless communication is of- 
ten bandwidth limited and has high latency, leading to 
slow communication. Current markup languages used 
in wired communications include those based on Hyper- 
text Markup Language (HTML), or Extensible Markup 
Language (XML), for example, and protocols like Hyper 
Text Transfer Protocol (HTTP), Transmission Control 
Protocol/Internet Protocol (TCP/IP), Infrared Data As- 
sociation (IrDA), or Bluetooth, for example. 

HTML 

[001 3J Source information which is stored in the 
source function is often stored in a format known as "Hy- 
pertext Martcup Language (HTML)'*. This file format al- 
lows the display of text, graphics and audio infomiatlon, 
and provides links to other pages of information through 
"hyperlinks." Hyperlinks are strings of characters in a 
particular format that specify the address of the desired 
page of infonnation. 

[00141 particular, HTML is a system for marking 
documents to indicate how the document should be dis- 
played, and how various documents should be linked 
together. HTML is a form of Standard Generalized 
Markup Language (SGML), defined by the International 
Standards Organization, but protocols using clear text 
HTML are bogged down In its versatility by its verbose- 
ness. An HTML document is made available to users on 
the web by storing the HTML file in a directory that is 
accessible by the server. Such a server is typically a web 
server which conforms to a web browser-supported pro- 
tocol known as HTTP. 



HTTP 

[001 5J HTTP defines a set of rules that servers and 
browsers follow when communicating with each other 

5 to access any type of content, including HTML. Typical- 
ly, the process begins when a user accesses an icon in 
an HTML page which is the anchor of a hyperlink, (for 
instance, by positioning a cursor on the icon and de- 
pressing a mouse button), or the user inputs a Uniform 

10 Resource Locator (URL) to the web browser. A connec- . 
tion is then made to the server at the address and port 
number specified by the URL. Next, the browser sends 
a request to retrieve an object from the server, or to post 
data to an object on the server. The server sends a re- 

*5 sponse to the browser including a status code and the 
response data. 

XML 



20 [0016] XML is the 'Extensible Markup Language' (ex- 
tensible because it is not a fixed format like HTML) man- 
aged by the World Wide Web Consortium . It is designed 
to enable the use of SGML (Standard Generalized 
Markup Language) on the World Wide Web. XML is not 

25 a single, predefined markup language: it's a metalan- 
guage - a language for describing other language - 
which lets the user design his/her own markup. A pre- 
defined markup language like HTML defines a way to 
describe information in one specific class of documents 

30 only; XML lets you define your own customized markup 
languages for limitless different classes of document. It 
can do this because it's written in SGML, the Interna- 
tional standard metalanguage for text martcup systems. 
The main handicap of protocols using XML is its ver- 

35 boseness. 

SyncML 

[0017] SyncML is a new industry initiative to develop 

40 and promote a single, common data synchronization 
protocol that can be used industry-wide. SyncML prod- 
ucts are not yet available, but it claims to successfully 
solve mobile computing Achilles' heel - data synchroni- 
zation. Mobile devices - handheld computers, mobile 

45 phones, pagers, laptops - synchronize their data with 
network applications, desktop calendars, and other lo- 
cations where infonnation is stored. This ability to ac- 
cess and update infonnation on the fly is key to the per- 
vasive nature of mobile computing. Yet, today, almost 

50 every device uses a different technology for performing 
data synchronization. SyncML tries to solve this by be- 
ing the common language for synchronizing all devices 
and applications over any network. SyncML uses XML. 
With SyncML, networked Infonnation can be synchro- 

55 nized with any mobile device, and mobile information 
can be synchronized with any networked applications. 
A disadvantage of SyncML is that products based on 
this markup language are not currently available. 
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DATA PACKETS 

[001 8] Data is transferred from one device to another 
not in a continuous stream, but in the fomn of packets 
which are divided into 2 parts, viz.; header and payload. 
The header contains information vital for error checking; 
and other protocol specifications, and is considered an 
overhead of each packet. The payload on the other hand 
is the section that contains the useful data, and is kept 
at an optimal length by all packets. Each packet has sim- 
ilar characteristics of all packets in a given transfer, and 
some of these may include length of each packet, and 
header content of each packet. Each packet has to be 
stored temporarily and analyzed by. each node in the 
network before it is fonwarded causing a delay. This de- 
lay, or network latency, is inherent in all contemporary 
protocols. Storage of each packet may be necessary be- . 
cause the speed at which a node receives a packet may 
be faster than the speed at which it can successfully for- 
ward it. Analysis of a package Is necessary to ensure 
an error free transfer of data, and part of the analysis is 
to send acknowledgement of the receipt of a packet by 
a node to the sender. This added overhead of analyzing 
is not desirable since contemporary networks have oth- 
er inherent layers that take care of error checking. 
[0019] Since the size of a packet is directly propor- 
tional to its transmission time, each medium, like fiber 
optic or wireless, uses a certain packet size to optimize 
its transmission time. Packet size also depends on the 
kind of network architecture, and network protocols. 
Some network architecture require the confimriation of 
each packet at every node in the network, as seen 
above, while others transmit packets over a route of 
least congestion, but this results in packets arriving at 
the destination non-sequentially. if the destination hap- 
pens to be a PDA it increases the burden on its limited 
memory and processing power. 

SUMMARY OF THE INVENTION 

[0020] It is an object of the invention to provide an im- 
proved protocol to connect between a client and a serv- 
er. 

[0021 ] This object of the invention is solved by method 
for connecting a client to a server comprising: generat- 
ing a connection message at said client and forwarding 
it to said server; receiving said connection message at 
said server and initiating a connection by sending an ac- 
knowledgement from said server to said client; gener- 
ating and sending a command from said client to said 
server; and receiving said command at said server and 
generating a forwarding response to said client, said for- 
warding response comprising a plurality of packets, 
each of said packets forwarded to said client without 
waiting for an acknowledgement of receipt from said cli- 
ent, and said packets containing arbitrary content. 
[0022] The arbitrary content may include, but is not 
limited to, text, streaming video, streaming audio, and 



images. 

[0023] The connection message may be generated at 
the application layer level at said client and may be re- 
ceived at said application layer level at said server. Fur- 

5 ther, the connection message may comprise identity 
and authentication information, and may comprise pro- 
tocol version infonnation, character encoding infomna- 
tion, and device type information. 
[0024] The command may be one of a group of com- 

10 mands including IDENTIFY & AUTHENTICATE, LIST, 
GET, REPLACE, ADD, DELETE. CANCEL, and LOG- 
OUT. 

[0025] The connection may comprise a wireless con- 
nection and may comprise a HTTP, or HTTPS connec- 
ts tion. 

[0026] The connection may end automatically after a 
timeout period. 

[0027] Each connection may be associated with a 
session Id and the command and response may include 

20 said session ID. 

[0028] The object of the invention is further solved by 
a client for connecting to a server comprising: means for 
generating a connection message and forwarding it to 
said server; means for receiving an acknowledgement 

25 from said server, generated at said server upon receiv- 
ing said connection message and initiating a connec- 
tion; means for generating and sending a command 
from said client to said server; and means for receiving 
a forwarding response, said fonwarding response being 

30 generated by said server and comprising a plurality of 
packets, each of said packets forwarded to said client 
without waiting for an acknowledgement of receipt from 
said client, and said packets containing arbitrary con- 
tent, 

35 [0029] The object of the invention is further solved by 
a server for connecting to a client comprising: means for 
receiving generated by said client; means for initiating 
a connection by sending an acknowledgement from said 
server to said client; means for receiving a command 

<o generated by said client; and means for generating a 
forwarding response to said client, said fonwarding re- 
sponse comprising a plurality of packets, each of said 
packets fonwarded to said client without waiting for an 
acknowledgement of receipt from said client, and said 

45 packets containing arbitrary content. 

[0030] The object of the invention is further solved by 
a computer program product comprising: a computer 
usable medium having computer readable program 
code means embodied in said medium for causing a 

50 computer to connect a client to a server, said computer 
readable program code means comprising: computer 
readable program code means for causing a computer 
to generate a connection message at said client and for- 
warding rt to said server; computer readable program 

55 code means for causing a computer to receive said con- 
nection message at said server and initiating a connec- 
tion by sending an acknowledgement from said server 
to said client; computer readable program code means 
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for causing a computer to generate and sending a com- 
mand from said client to said server; and computer read- 
able program code means for causing a computer to re- 
ceive said command at said server and generating a for- 
warding response to said client, said forwarding re- 
sponse comprising a plurality of packets, each of said 
packets forwarded to said client without waiting for an 
acknowledgement of receipt from said client, and said 
packets containing arbitrary content. 
[0031 J A program may have instructions adapted to 
make a computer carry out the method of the above op- 
erations and a computer readable medium may include 
the program. 

[0032] Further advantageous features of the inven- 
tion are disclosed in further claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0033] These and other features, aspects and advan- 
tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims and accompanying drawings where: 

Fig. 1 is an illustration of a wireless device such as 
a PDA. 

Fig. 2 is an illustration of a PDA coupled with a 
desktop computer via a conduit. 

Fig. 3 is a flowchart which shows the transfer of a 
file to and from a wireless device. 

Fig. 4 is a flowchart which shows the various oper- 
ations after the client initiates the transfer. 

Fig. 5 is an illustration" of the Identify and Authenti- 
cate operation. It shows a table of the packet 
content that the client sends to the server, 
and another table of the packet content that 
it receives from the server. 

Fig. 6 is an illustration of the List operation . It shows 
a table of the packet content that the client 
sends to the server, and another table of the 
packet content that it receives back from the 
server. 

Fig. 7 is an illustration ofthe Get operation. It shows 
a table of the packet content that the client 
sends to the server, and another table of the 
packet content that it receives back from the 
server. 

Fig. 8 is an illustration of the Replace operation. It 
shows a table of the packet content that the 
client sends to the server, and another table 
of the packet content that it receives back 
from the server. 



Fig. 9 isanillustrationofthe Addoperation. Itshows 
a table of the packet content that the client 
sends to the server, and another table of the 
packet content that it receives back from the 
5 server. 

Fig. 10 is an illustration of the Delete operation. It 
shows a table of the packet content that the 
client sends to the server, and another table 
10 of the packet content that it receives back 

from the server. 

Fig. 11 is an illustration of the Cancel operation. It 
shows a table of the packet content that the 
'5 client sends to the server, and another table 

of the packet content that it receives back 
from the server. 

Fig. 12 is an illustration of the Logout operation. It 
20 shows a table of the packet content that the 

client sends to the server, and another table 
of the packet content that it receives back 
from the server. 

25 Fig. 13 is a flowchart illustratirig some of the at- 
tributes of the Identify and Authenticate com- 
mand. 

Fig. 14 is a flowchart illustrating some of the at- 
30 tributes of the Get command. 

Fig. 15 is an illustration of an embodiment of a com- 
puter execution environment. 

35 DETAILED DESCRIPTION OF THE INVENTION 

[0034] The invention provides a protocol for connect- 
ing electronic devices, and the transfer of files to and . 
from electronic devices, especially wireless devices. In 

40 the following description, numerous specific details are 
set forth to provide a more thorough description of em- 
bodiments of the invention. It is apparent, however, to 
one skilled in the art, that the invention may be practiced 
without these specific details, In other instances, well 

45 known features have not been described in detail so as 
not to obscure the invention. 

[0035] The present invention provides a protocol for 
connecting electronic devices, and the transfer of files 
to and from electronic devices, especially wireless de- 
50 vices. In one embodiment, the present invention is used 
by these devices connected by any means to the source 
of the file. These means can be wireless, modem dial- 
up, or conduit of a PDA. Since this protocol is used by 
wireless devices which operate on limited and expen- 
ds sive wireless bandwidth, it is not verbose and "chatty" 
unlike prior art protocols based on clear-text HTML, 
XML, or HotSync. The present invention uses HTTP or 
Hypertext Transfer Protocol - Secure (HTTPS, also 
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known as Secure Socket Layer, or SSL) for enhanced 
security reasons to connect two devices connnnunicating 
with each other. HTfP is used since it is a protocol that 
is generally allowed to traverse virtual private network 
firewalls. 

[0036] According to one ennbodiment. the invention 
allows the server to maintain multiple sessions with dif- 
ferent clients. These sessions will end automatically if 
no data is transfen^ed after a certain length of time has 
elapsed. These different clients can connect and per- 
form operations concurrently with each other According 
to another embodiment, the present invention supports 
the following operations, viz.: Identify and Authenticate, 
List, Get, Replace, Add, Delete, Cancel, and Logout. In 
another embodiment, the invention allows for synchro- 
nous transfer of messages to and from the wireless de- 
vices. The present invention, in yet another embodi- 
ment, lets the client initiate the transfer. The server does 
not automate the transfer unless a request is made by 
the client. In yet another embodiment, the initial hand- 
shake package of the protocol includes the desired pro- 
tocol version, (this allows the protocol to evolve over 
time). 

DATA FORMAT 

[0037] The present invention supports the same wire 
fomnats for primitive types as those used by Java's data 
input/output stream. If the device using the present in- 
vention supports strings in the UTF-8 format, then the 
protocol transmits data in that fonnat, otherwise the pro- 
tocol will send the data in a 8-bit extended-ASCI I format, 
like 1S08859. Both these fomnats have a very short 
header which increases the space in every packet for 
the payload. All strings in the protocol are preceded by 
an Int16 length. This is a short length in JAVA, as op- 
posed to Int32 length, which is a long length. All strings 
in the present protocol are not null-terminated. This 
means that the last bit of each string is not used by a 
non-data value like the hull character Hence by making 
use of all the available bits in the payload for useful data 
transmission, the present protocol further reduces 
terseness and chattiness. Finally, all integers are 
signed. Signed integers are used in order to have com- 
patibility across languages such as Java and C. This 
compatibility allows clients to be written in C, and the 
server in Java, for example, or vice-versa. 

CONNECTION 

[0038] According to one embodiment, the present in- 
vention is used by a device connected directly to the 
source of the transfer file. This source is referred to as 
the server, while the destination is referred to as the cli- 
ent. This setup is seen in Figure 3, where at step 300 
the client is connected to the server. This connection can 
be in the fonn of a dial-up modem, wireless, or conduit. 
Conduits can be of two kinds, viz.: a wire cable that con- 



nects a PDA to a desktop (as seen at 230 in Figure 2), 
or a relay er conduit that connects a wireless device to 
a desktop. Next at step 301 the file to be transferred is 
chosen, and at step 302 it Is transfen-ed. Furthermore 
5 according to one embodiment, the present invention 
supports all file types containing any arbitrary content. 
This content may include, and is not limited to, text, 
records (in the fomn of a database), streams (video like 
MPEG or JPEG, oraudio like MPS or RealAudio), or im- 
'0 ages (.tiff, .gif, etc.). 

[0039] The present invention uses HTTP to connect 
a client to a server because HTTP is a that is usually 
allowed to traverse virtual private network (VPN) fire- 
walls. HTTP is widely supported and implemented on 
'5 both server (HTTPServlet) and client (the INet library on 
the Palm VII) sides and is an industry standard. The 
present invention can also use HTTPS, if additional se- 
curity is required, to connect a client to a server. The 
reason the present invention can use a lower level pro- 
20 tocol like HTTP is because the present invention runs 
at the Application layer level (topmost level) in the ISO 
7-layer model, unlike prior art protocols that run either 
attheDataLink layer level (for example TCP), or the Net- 
work layer level (for example IP). 
25 [0040] The present invention allows a server to main- 
tain concurrent sessions with multiple clients, according 
to one embodiment. These clients in turn are able to per- 
form their operations concurrent to each other. Since cli- 
ents do not have to wait in a queue to have their sessions 
30 served by a server, the cost of connectivity is reduced 
and transfers are conducted in a minimum of time. 

TRANSFER OF DATA 

35 [0041] In one embodiment, the invention supports 
synchronous transfer of data (may be in the fomn of files) 
to and from wireless devices. Synchronous transfer is 
when the user issues more than one request, the re- 
quests are complied with in the order received. For ex- 

40 ample, if the user sends a request to Print a certain doc- 
ument, and subsequently sends another request to 
Save the same document, the Save will be complied 
with only after the Print is completed. 
[0042] Figure 4 illustrates the various operations that 

45 the present protocol supports after the client has initiat- 
ed the transfer At step 400, a client is connected to a 
server Next, at step 401 , the list of files on the server is 
displayed to the client. The client has several operations 
at this point that he/she can choose from, and at step 

50 402, if the Get operation is used, then the necessary 
files are transferred from the server to the client at step 
403. If the Delete operation is used instead at step 404, 
then at step 405 the necessary files are deleted from the 
server. If the Add operation is used instead at step 406, 

55 then at step 407 the necessary files are transferred from 
the client to the server If the Replace operation is used 
instead at step 408, then at step 409 the necessary files 
are transferred from the client to the server 
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[0043] The present invention supports the Identify 
and Authenticate List, Get, Replace, Add, Delete, Can- 
cel, and Logout operations, and are illustrated in more 
detail in Figures 5 through 14. 

A) Identify and Authenticate - A client will be able to 
identify itself with a user identity, such as a user- 
name, and authenticate itself with a user password. 
The password can be chosen by the user under cer- 
tain conditions, or can be set by the administrator 
of the server. In both cases, the present invention 
keeps the password anonymous to deter unauthor- 
ized clients. This operation is illustrated in Figure 5, 
where the contents of the packet sent to and from 
a server are shown in tabular format. 

One aspect of the Identify and Authenticate op- 
eration denotes the device type, operating system, 
and screen size and depth. By virtue of the kind of 
device the client is hosted on, these attributes let 
the server format the data to be sent back to the 
client. An example of this is seen in Figure 13, 
where at step 1 300 the device type is given to the 
server by the client. Next, at step 1 301 , the operat- 
ing system type is given to the server. Next, at step 
1 302, the screen size and depth is given to the serv- 
er. At step 1303, if the client is hosted on a device 
that supports color, then this information along with 
any other graphics related infonnation is given to 
the server. Finally, at step 1 304, the server uses the 
information received at steps 1300 through 1303 to 
format the data to be sent back to the client. This 
way the client gets the data in a format suitable for 
the kind of device he/she is hosted on. Since infor- 
mation that helps in formatting the data to be re- 
ceived by a client is sent once during the Identify 
and Authenticate operation, the client does not 
have to send this information or portions thereof in 
future commands. This helps in reducing the "chat- 
tiness" of the present protocol, and helps In using 
the limited and expensive bandwidth of a wireless 
connection more economically. 

After the connection has been established, the 
user may perform several tasks, like listing all avail- 
able files, getting files, replacing files, adding files, 
deleting files, canceling an operation, and logging 
out, which can be executed using the appropriate 
commands. These commands are explained in fur- 
ther detail below. 

B) List - A client is able to obtain a list of all files 
available for transfer to it. Along with the name of 
the file, other attributes like its size, date of creation, 
and date of last modification are also transferred. 
This allows for similar infonmation regarding the files 
be available to both the server and client. An illus- 
tration of the contents of a packet to and from a serv- 
er is seen In Figure 6. 



C) Get - A client is able to transfer a file using this 
operation. The present protocol allows for the trans- 
fer of multiple files with the help of one single Get 
request. As seen earlier, this is one way that the 

5 present invention reduces chattiness. Figure 7 
shows an illustration of the Get operation. The 
number of elements in the returned array found in 
the packet that the client receives from the server 
must be equal to the count of documents requested. 

10 If this count is unequal, the transfer of infonnation 
to and from the server was not successful, and the 
client has the choice of re-submitting the request or 
postponing it to a later time. 

The document number, size, and data at- 

15 tributes that the client receives from the server in- 
dicates whether the Get command was successfully 
executed or not. An example run Is shown in Figure 
1 4 where at step 1 400 a server receives the Get 
command from a client. Based on the count of doc- 

20 uments to get (which is an attribute of the Get com- 
mand that the client sends to the server), the server 
determines the document number at step 1401. 
Since the present protocol supports multiple docu- 
ments that can be sent using just one Get com- 

25 mand, the client can specify more than one docu- 
ment from the server. Next, at step 1402, the size 
of each document is determined by the server. At 
step 1 403, the documents are sent to the client. The 
client receives the documents at step 1404. Next, 

30 at step 1405, the document number and size is 
checked by the client to determine if the Get com- 
mand was successful or not. If the document 
number and size match what the client requested, 
then at step 1406 the client knows that the Get op- 

35 eration was successful. If on the other hand the doc- 
ument number and size do not match, then at step 
1407 the client knows that the Get operation was 
unsuccessful, and can decide if the operation needs 
to be complied with again or can be postponed to a 

-^0 later time. 

D) Replace - A client is able to replace an existing 
file on a server using this operation. If the replace 
is not completely successful, the present invention 

^5 lets the client know of the failure, and restores the 
older version on the server. In this way. the older 
version of the file is not lost on the server. As dis- 
cussed earlier, the client only finds out at the end of 
the request whether it was successful or not. An il- 

50 lustration of the Replace operation is seen in Figure 
8, where the first table shows the packet content 
that the client sends to the server, and the second 
table is what is sent back by the server to the client. 

55 E) Add - A client uses this operation to transfer a 
new file to a server. The file to be transferred can 
either be created by the user on the client side, or 
have the file transferred to it from some other 
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source. An illustration of the Add operation is seen 
in Figure 9, where the first table shows the contents 
of the packet sent to the server by the client, and 
the second table shows the content of the return 
packet. 

F) Delete - With this operation, if a file is deleted 
from the client side before the client is synchronized 
with a server, the file is also deleted from the server. 
An illustration of the Delete operation is seen in Fig- 
ure 10, where the first table shows the contents of 
the packet sent to the server by the client, and the 
second table shows the content of the return pack- 
et. 

G) Cancel - With this operation, a client has the op- 
tion to cancel any potentially lengthy operation. An 
illustration of the Cancel operation is seen In Figure 
11 , where the first table shows the contents of the 
packet sent to a server by the client, and the second 
table shows the content of the return packet. This 
operation can be performed asynchronously. 

H) Logout - With this operation, a client can close 
or end a session with a server. If any other opera- 
tions are in progress when the Logout request is is- 
sued, they get tenninated as well. An illustration of 
the Logout operation is seen in Figure 12, where 
the first table shows the contents of the packet sent 
to the server by the client, and the second table 
shows the content of the return packet. This oper- 
ation can be perfonmed asynchronously. 

ADVANTAGE OVER PRIOR ART SCHEMES 

. [0044] In all the operations mentioned above, a client 
makes a request to a server, which is received without 
any error checking steps at each node. Similarly, these 
requests are complied by the server without any en-or 
checks made at individual nodes along the way. An en-or 
checking step eliminated by this protocol is the acknowl- 
edgement (ACK) or non-acknowledgement (NACK) of 
a packet received at each node. In prior art, there is an 
ACK/NACK sent back to the sender by each receiving 
node in the network. This ACK/NACK is sent in different 
ways depending on the kind of protocol. Some allow the 
receiver to send an ACK/NACK for every packet re- 
ceived, which forces the sender to wait before the next 
packet can be sent. Others allow the receiver to send 
an ACK/NACK after a certain fixed number of packets 
received. While still others allow the sender to keep 
transmitting the packets simultaneously while ACKs/ 
NACKs are sent back to it by the receiver. All these 
methods increase the time of transmittal, which the 
present invention boasts of- eliminating because wire- 
less devices use a limited and expensive bandwidth to 
transmit data and ACKs/NACKs increase the verbose- 
ness of a protocol. 



[0045] Since there are no ACKs/NACKs sent to the 
sender, the receiver may either get the entire transfer 
successfully, or there may be sections missing. This 
present invention wilt let the receiver know just once (at 
5 the end of an operation) if it was successful or not. It is 
up to the sender to retransmit the operation or to post- 
pone it for another time. 

EMBODIMENT OF A COMPUTER EXECUTION 
10 ENVIRONMENT 

[0046] An embodiment of the invention can be imple- 
mented as computer software in the fonn of computer 
readable code executed in a desktop general purpose 

^5 computing environment such as environment 1 500 illus- 
trated in Figure 1 5, or in the form of bytecode class files 
running in such an environment. A keyboard 1510 and 
mouse 1511 are coupled to a bi-directional system bus 
1518. The keyboard and mouse are for introducing user 

20 input to a computer 1501 and communicating that user 
input to processor 1513. 

[0047] Computer 1501 may also include a communi- 
cation interface 1520 coupled to bus 1518, Communi- 
cation interface 1520 provides a two-way data commu- 

25 nication coupling via a network link 1521 to a local net- 
work 1522. For example, if communication interface 
1520 is ah integrated services digital network (ISDN) 
card or a modem, communication interface 1520 pro- 
vides a data communication connection to the corre- 

30 spending type of telephone line, which comprises. part 
of network link 1 521 . If communication interface 1 520 is 
a local area network (LAN) card, communication inter- 
face 1520 provides a data communication connection 
via network link 1521 to a compatible LAN. Wireless 

35 links are also possible. In any such implementation, 
communication interface 1 520 sends and receives elec- 
trical, electromagnetic or optical signals, which carry 
digital data streams representing various types of infor- 
mation. 

40 [0048] Network link 1 521 typically provides data com- 
munication through one or more networks to other data 
devices. For example, network link 1521 may provide a 
connection through local network 152 to local server 
computer 1523 or to data equipment operated by ISP 

45 1524. ISP 1524 in turn provides data communication 
services through the world wide packet data communi- 
cation network now commonly referred to as the "Inter- 
net' 1525. Local network 1522 and Internet 1525 both 
use electrical, electromagnetic or optical signals, which 

50 canry digital data streams. The signals through the var- 
ious networks and the signals on network link 1 521 and 
through communication interface 1520, which carry the 
digital data to and from computer 1500, are exemplary 
forms of carrier waves transporting the infonnation. 

55 [0049] Processor 1513 may reside wholly on client 
computer 1501 or wholly on server 1526 or processor 
1513 may have its computational power distributed be- 
tween computer 1501 and server 1526. In the case 
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where processor 1513 resides wholly on server 1526, 
the results of the computations perfomned by processor 
1513 are transmitted to computer 1501 via Internet 
1525. internet Sen/ice Provider (ISP) 1524. local net- 
work 1522 and communication interface 1520. In this s 
way, computer 1 501 is able to display the results of the 
computation to a user in the fomri of output. Other suit- 
able input devices nriay be used in addition to, or in place 
of. the mouse 1111 and keyboard 1110. I/O (input/out- 
put) unit 1119 coupled to bi-directional system bus 1118 io 
represents such I/O elements as a printer, A/V (audio/ 
video) I/O, etc.. 

[0050] Computer 1501 includes a video memory 
1514, main memory 1515 and mass storage 1512, all 
coupled to bi-directional system bus 1518 along with '5 
keyboard 1510. mouse 1511 and processor 1513. 
[0051] As with processor 1513, in various computing 
environments, main memory 1515 and mass storage 
1512, can reside wholly on server 1526 or computer 
1501 , or they may be distributed between the two. Ex- 20 
amples of systems where processor 1513, main mem- 
ory 1515, and mass storage 1512 are distributed be- 
tween computer 1 501 and server 1 526 include the thin- 
client computing architecture developed by Sun Mi- 
crosystems, Inc., the palm pilot computing device, Inter- 25 
net ready cellular phones, and other Internet computing 
devices. 

[0052] The mass storage 1512 may include both fixed 
and removable media, such as magnetic, optical or 
magnetic optical storage systems or any other available 3o 
mass storage technology. Bus 1 51 8 may contain, for ex- 
ample, thirty-two address lines for addressing video 
memory 1514 or main memory 1515. The system bus 
1518 also includes, for example, a 32-bit data bus for 
transferring data between and among the components, 55 
such as processor 1513, main memory 1515. video 
memory 1514, and mass storage 1512. Alternatively, 
multiplex data/address lines may be used instead of 
separate data and address lines. 

[0053] In one embodiment of the invention, the proc- 40 
essor 1513 is a microprocessor manufactured by Mo- 
torola, such as the 680X0 processor or a microproces- 
sor manufactured by Intel, such as the 80X86, or Pen- 
tium processor, or a SPARC microprocessor from Sun 
Microsystems, Inc. However, any other suitable micro- 
processor or microcomputer may be utilized. Main 
memory 1515 is comprised of dynamic random access 
memory (DRAM). Video memory 1514 is a dual-ported 
video random access memory. One port of the video 
memory 1514 is coupled to video amplifier 1516. The so 
video amplifier 1516 is used to drive the cathode ray 
tube (CRT) raster monitor 1517, Video amplifier 1516 is 
well known in the art and may be implemented by any 
suitable apparatus. This circuitry converts pixel data 
stored in video memory 1514 to a raster signal suitable 55 
for use by monitor 1 51 7. Monitor 1 51 7 is a type of mon- 
itor suitable for displaying graphic images. 
[0054] Computer 1501 can send messages and re- 



ceive data, including programcode, through the network 
(s), network link 1521. and communication interface 
1520. In the Internet example, remote server computer 
1526 might transmit a requested code for an application 
program through Internet 1525, ISP 1524, local network 
1522 and communication Interface 1520. The received 
code may be executed by processor 1513 as it is re- 
ceived, and/or stored in mass storage 1512. or other 
non-volatile storage for later execution. In this manner, 
computer 1500 may obtain application code in the form 
of a carrier wave. Alternatively, remote server computer 
1526 may execute applications using processor 1513, 
and utilize mass storage 1512, and/or video memory 
1515. The results of the execution at server 1526 are 
then transmitted through Internet 1525, ISP 1524. local 
network 1522. and communication interface 1520. In 
this example, computer 1501 performs only input and 
output functions. 

[0055] Application code may be embodied in any form 
of computer program product. A computer program 
product comprises a medium configured to store or 
transport computer readable code, or in which computer 
readable code may be embedded. Some examples of 
computer program products are CD-ROM disks. ROM 
cards, floppy disks, magnetic tapes, computer hard 
drives, servers on a network, and carrier waves. 
[0056] The computer systems described above are 
for purposes of example only. An embodiment of the in- 
vention may be implemented in any type of computer 
system or programming or processing environment. 
[0057] Thus, a protocol for the transfer of files to and 
from electronic devices, especially wireless devices is 
described in conjunction with one or more specific em- 
bodiments. The invention is defined by the following 
claims and their full scope of equivalents. 
[0058] Further, according to another embodiment, a 
client for connecting to a server may comprise: means 
for generating a connection message and forwarding it 
to said server; means for receiving an acknowledge- 
ment from said server, generated at said server upon 
receiving said connection message and initiating a con- 
nection; means for generating and sending a command 
from said client to said server; and means for receiving 
a forwarding response, said forwarding response being 
generated by said server and comprising a plurality of 
packets, each of said packets forwarded to said client 
without waiting for an acknowledgement of receipt from 
said client, and said packets containing arbitrary con- 
tent. 

[0059] Further, according to another embodiment, a 
server for connecting to a client may comprise: means 
for receiving generated by said client; means for initiat- 
ing a connection by sending an acknowledgement from 
said server to said client; means for receiving a com- 
mand generated by said client; and means for generat- 
ing a forwarding response to said client, said forwarding 
response comprising a plurality of packets, each of said 
packets forwarded to said client without waiting for an 
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acknowledgement of receipt from said client, and said 
packets containing arbitrary content. 
[0060] Further, It is noted that a computer-readable 
medium may be provided having a program embodied 
thereon, where the program Is to make a computer or a 5 
system of data processing devices to execute functions 
or operations of the features and elements of the above 
described examples. A computer-readable medium can 
be a magnetic or optical or other tangible medium on 
which a program is recorded, but can also be a signal, 
e.g. analog or digital, electronic, magnetic or optical, in 
which the program is embodied for transmission. Fur- 
ther, a computer program product may be provided com- 
prising the computer-readable medium. 
[0061] A program may have instmctions adapted to 
make a computer carry out the operations of the above 
embodiments. A computer readable medium, in which 
a program is embodied, where the program is to make 
a computer execute the operations of the above embod- 
iments. 

[0062] According to another embodiment, an article 
of manufacture may have the following structure. 



2) The article of manufacture of 1) wherein said 
packets contain arbitrary content includes, and is 

' not limited to, text, streaming video, streaming au- 
dio, and Images. 

3) The article of manufacture of 1 ) wherein said con- 
nection message is generated at the application 
layer level at said client. 

4) The article of manufacture of 1 ) wherein said con- 
nection message is received at said application lay- 
er level at said server. 

5) The article of manufacture of 1) wherein compu- 
ter readable program code configured to cause said 
computer to generate a connection message com- 
prises Identity and authentication information. 

6) The article of manufacture of 1 ) wherein said con- 
nection message comprises protocol version infor- 
mation, character encoding infomriation, and device 
type information. 

7) The article of manufacture of 1) wherein said 
computer readable program code configured to 
cause said computer to receive said command is 
one of a group of commands including IDENTIFY & 
AUTHENTICATE, LIST, GET REPLACE, ADD, DE- 
LETE. CANCEL, and LOGOUT 

8) The article of manufacture of i ) wherein said con- 
nection comprises a wireless connection. 

9) The article of manufacture of 1 ) wherein said con- 
nection comprises a HTTP, or HTTPS connection. 

10) The article of manufacture of 1) wherein said 
connection ends automatically after a timeout peri- 
od. 

11) The article of manufacture of 1) wherein each 
said connection is associated with a session ID. 

12) The article of manufacture of 11) wherein said 
command and response includes said session ID. 

[0063] According to another embodiment a method 
for connecting a client to a server may comprise; gen- 
erating a connection message at said client and for- 
warding it to said server; receiving an acknowledgement 
from said server at said client, generated at said server 
upon receiving said connection message and initiating 
a connection; generating and sending a command from 
said client to said server; and receiving a forwarding re- 
sponse at said client, said forwarding response being 
generated by said server and comprising a plurality of 
packets, each of said packets forwarded to said client 
without waiting for an acknowledgement of receipt from 



1) An article of manufacture comprising: 

25 

a computer usable medium having computer 
readable program code embodied therein for 
connecting a client to a server, said computer 
readable program code In said article of manu- 
facture comprising: 30 

computer readable program code config- 
ured to cause said computer to generate a 
connection message at said client and for- 
warding it to said server; 35 

computer readable program code config- 
ured to cause said computer to receive 
said connection message at said server 
and initiate a connection by sending an ac- 40 
knowledgement from said server to said 
client; 

computer readable program code config- 
ured to cause said computer to generate ^5 
and send a command from said client to 
said server; and 

computer readable program code config- 
ured to cause said computer to receive so 
said command at said server and generate 
a fonvarding response to said client, said 
forwarding response to comprise a plurality 
of packets, jsach of said packets forwarded 
to said client without waiting for an ac- 55 
knowledgement of receipt from said client, 
and said packets containing arbitrary con- 
tent. 
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said client, and said packets containing arbitrary con- 
tent. 

[0064] According to yet another embodiment a meth- 
od for connecting a client to a server may comprise: re- 
ceiving a connection message at said server generated 
by said client; initiating a connection by sending an ac- 
knowledgement from said server to said client; receiving 
a command at said server generated by said client; and 
generating a fonwarding response to said client, said for- 
warding response comprising a plurality of packets, 
each of said packets fonwarded to said client without 
waiting for an acknowledgement of receipt from said cli- 
ent, and said packets containing arbitrary content. 

Claims 

• 1. A method for connecting a client to a sen/er com- 
prising: 

generating a connection message at said client 
and forwarding it to said server; 

receiving said connection message at said 
server and initiating a connection by sending 
an acknowledgement from said server to said 
client; 

generating and sending a command from said 
client to said server; and 

receiving said command at said server and 
generating a forwarding response to said client, 
said forwarding response comprising a plurality 
of packets, each of said packets forwarded to 
said client without waiting for an acknowledge- 
ment of receipt from said client, and said pack- 
ets containing arbitrary content. 

2. The method of claim 1 wherein said arbitrary con- 
tent includes, and is not limited to, text, streaming 
video, streaming audio, and images. 

3. The method of at least one of claims 1 and 2 where- 
in said connection message is generated at the ap- 
plication layer level at said client. 

4. The method of at least one of claims 1 to 3 wherein 
said connection message is received at said appli- 
cation layer level at said server. 

5. The method of at least one of claims 1 to 4 wherein 
said connection message comprises identity and 
authentication information. 

6. The method of at least one of claims 1 to 5 wherein 
said connection message comprises protocol ver- 
sion information, character encoding infomriation, 



and device type information. 

7. The method of at least one of claims 1 to 6 wherein 
said command is one of a group of commands in- 

5 eluding IDENTIPT & AUTHENTICATE. LIST, GET, 
REPLACE, ADD, DELETE, CANCEL, and LOG- 
OUT 

8. The method of at least one of claims 1 to 7 wherein 
10 said connection comprises a wireless connection. 

9. The method of at least one of claims 1 to 8 wherein 
said connection comprises a HTTP, or HTTPS con- 
nection. 

15 

10. The method of at least one of claims 1 to 9 wherein 
said connection ends automatically after a timeout 
period. 

20 11. The method of at least one of claims 1 to 1 0 wherein 
each connection is associated with a session ID. 

1 2. The method of claim 1 1 wherein said command and 
response includes said session ID. 

25 

13. A client for connecting to a server comprising: 

means for generating a connection message 
and fon/varding it to said server; 

30 

means for receiving an acknowledgement from 
said server, generated at said server upon re- 
ceiving said connection message and initiating 
a connection; 

35 

means for generating and sending a command 
from said client to said server; and 

means for receiving a fonwarding response, 
40 said forwarding response being generated by 

said server and comprising a plurality of pack- 
ets, each of said packets forwarded to said cli- 
ent without waiting for an acknowledgement of 
receipt from said client, and said packets con- 
^5 taining arbitrary content. 

14. The client of claim 1 3 wherein said arbitrary content 
includes, and is not limited to, text, streaming video, 
streaming audio, and images. 

50 

15. The client of at least one of the claims 13 and 14 
wherein said connection message is generated at 
the application layer level at said client; 

55 1 6. The client of at least one of claims 1 3 to 1 5 wherein 
said connection message comprises identity and 
authentication Infonmation. 
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1 7. The client of at least one of claims 1 3 to 1 6 wherein 
said connection message comprises protocol ver- 
sion infonmatlon, character encoding infonnation, 
and device type infonnation. 

1 8. The client of at least one of claims 1 3 to 1 7 wherein 
said command Is one of a group of commands in- 
cluding IDENTIFY & AUTHENTICATE. USX GET. 
REPLACE. ADD. DELETE; CANCEL, and LOG- 
OUT 



28. The server of at least one of claims 24 to 27 wherein 
said connection message comprises protocol ver- 
sion Infonmation, character encoding infonnation, 
and device type infonnation. 

5 

29. The server of at least one of claims 24 to 28 wherein 
said command is one of a group of commands in- 
cluding IDENTIFY & AUTHENTICATE, LIST. GET 
REPLACE, ADD. DELETE, CANCEL, and LOG- 

10 OUT 



19. The client of at least one of claims 13 to 18 wherein 
said connection comprises a wireless connection. 

20. The client of at least one of claims 1 3 to 1 9 wherein 
said connection comprises a HTTP, or HTTPS con- 
nection. 

21 . The client of at least one of claims 1 3 to 20 wherein 
said connection ends automatically after a timeout 
period. 

22. The client of at least one of claims 13 to 21 wherein 
each connection is associated with a session ID. 

23. The client of claim 22 wherein said command and 
response includes said session ID. 

24. A server for connecting to a client comprising: 

means for receiving generated by said client; 

means for initiating a connection by sending an 
acknowledgement from said server to said cli- 
ent; 

means for receiving a command generated by 
said client; and 

means for generating a forwarding response to 
said client, said forwarding response compris- 
ing a plurality of packets, each of said packets 
fonwarded to said client without waiting for an 
acknowledgement of receipt from said client, 
and said packets containing arbitrary content. 

25. The server of claim 24 wherein said arbitrary con- 
tent includes, and is not limited to, text, streaming 
video, streaming audio, and images. 

26. The server of at least one of claims 24 and 25 
wherein said connection message is received at 
said application layer level at said server. 

27. The server of at least one of claims 24 to 26 wherein 
said connection message comprises identity and 
authentication infonnation. 



30. The server of at least one of claims 24 to 29 wherein 
said connection comprises a wireless connection. 

'5 31 . The server of at least one of claims 24 to 30 wherein 
said connection comprises a HTTP, or HTTPS con- 
nection. 

32. The server of at least one of claims 24 to 31 wherein 
^0 said connection ends automatically after a timeout 

period. 

33. The server of at least one of claims 24 to 32 wherein 
each connection is associated with a session ID. 

25 

34. The server of claim 33 wherein said command and 
response includes said session ID. 

35. A computer program product comprising: 

30 

a computer usable medium having computer 
readable program code means embodied in 
said medium for causing a computer to con nect 
a client to a server, said computer readable pro- 
35 gram code means comprising: 

computer readable program code means 
for causing a computer to generate a con- 
nection message at said client and for- 
40 warding it to said server; 

computer readable program code means 
for causing a computer to receive said con- 
nection message at said server and initiat- 
ing a connection by sending an acknowl- 
edgement from said server to said client; 

computer readable program code means 
for causing a computer to generate and 
50 sending a command from said client to said 

server; and 

computer readable program code means 
for causing a computer to receive said 
55 command at said server and generating a 

f onwarding response to said client, said for- 
warding response comprising a plurality of 
packets, each of said packets forvi^arded to 
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said client without waiting for an acknowl- 
edgement of receipt from said client, and 
said packets containing arbitrary content. 

36. The computer program product of claim 35 wherein 
said arbitrary content includes, and is not limited to, 
text, streaming video, streaming audio, and images. 

37. The computer program product of at least one of 
claims 35 and 36 wherein said connection message 
is generated at the application layer level at said cli- 
ent. 

38. The computer program product of at least one of 
claims 35 to 37 wherein said connection message 
is received at the application layer level at said serv- 
er 

39. The computer program product of at least one of 
claims 35 to 38 wherein said connection messages 
comprises identity and authentication infomnation. 

40. The computer program product of at least one of 
claims 35 to 39 wherein said connection message 
comprises protocol version infomnation, character 
encoding information, and device type information. 

41 . The computer program product of at least one of 
claims 35 to 40 wherein said command is one of a 
group of commands including IDENTIFY & AU- 
THENTICATE. LIST GET, REPLACE. ADD. DE- 
LETE, CANCEL, and LOGOUT 

42. The computer program product of at least one of 
claims 35 to 41 wherein said connection comprises 
a wireless connection. 

43. The computer program product of at least one of 
claims 35 to 42 wherein said connection comprises 
a HTTP, or HTTPS connection. 

44. The computer program product of at least one of 
claims 35 to 43 wherein said connection ends au- 
tomatically after a timeout period. 

45. The computer program product of at least one of 
claims 35 to 44 wherein each connection is associ- 
ated with a session ID. 

46. The computer program product of claim 45 wherein 
said command and response includes said session 
ID. 

47. A program having instructions adapted to make a 
computer carry out the method of at least one of the 
claims 1-12. 

48. A computer readable rriedium, in which a program 



is embodied, where the program is to make a com- 
puter execute the method of at least one of the 
claims 1-12. 
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